elm322 elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > connection diagram pdip and soic (top view) v dd v ss obd (vpw) to rs232 interpreter since the 1996 model year, north american automobiles have been required to provide an obd, or on board diagnostics, port for the connection of test equipment. data is transferred serially between the vehicle and the external equipment using these connections, in a manner specified by the society of automotive engineers (sae) standards. in addition to operating at different voltage levels, these ports also use a data format that is not compatible with the standard used for personal computers. the elm320 is an 8 pin integrated circuit that is able to change the data rate and reformat the obd signals into easily recognized ascii characters. this allows virtually any personal computer to communicate with an obd equipped vehicle using only a standard serial port and a terminal program. by also enhancing it with an interface program, hobbyists can create their own custom ?can tool? this integrated circuit was designed to provide a cost-effective way for experimenters to work with an obd system, so many features such as rs232 handshaking, variable baud rates, etc., have not been implemented. in addition, this device is only able to communicate using the 10.4khz j1850 vpw protocol that is commonly used in general motors and some daimler chrysler vehicles. low power cmos design high current drive outputs - up to 25 ma crystal controlled for accuracy configurable with at commands standard ascii character output high speed rs232 communications 10.4khz j1850 vpw protocol diagnostic trouble code readers automotive scan tools obdout tx description applications block diagram 1 of 10 features elm322dsb obdin rx 1 2 3 8 7 6 5 4
elm322 elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > pin descriptions ordering information these integrated circuits are available in either the 300 mil plastic dip format, or in the 200 mil soic surface mount type of package. to order, add the appropriate suffix to the part number: 300 mil plastic dip............................... ELM322P 200 mil soic..................................... elm322sm 2 of 10 all rights reserved. copyright 2001 - 2002 elm electronics. every effort is made to verify the accuracy of information provided in this document, but no representation or warranty can be given and no liability assumed by elm electronics with respect to the accuracy and/or use of any products or information described in this document. elm electronics will not be responsible for any patent infringements arising from the use of these products or information, and does not authorize or warrant the use of any elm electronics product in life support devices and/or systems. elm electronics reserves the right to make changes to the device(s) described in this document in order to improve reliability, function, or design. v dd (pin 1) this pin is the positive supply pin, and should always be the most positive point in the circuit. internal circuitry connected to this pin is used to provide power on reset of the microprocessor, so an external reset signal is not required. refer to the electrical characteristics section for further information. xt1 (pin 2) and xt2 (pin 3) a 3.579545mhz ntsc television colourburst crystal is connected between these two pins. crystal loading capacitors (typically 27pf) will also normally be connected between each of the pins and the circuit common (vss). obdin (pin 4) the obd data is input to this pin, with a low logic level representing the active state (and a high, the passive). no schmitt trigger input is provided, so the obd signal should be buffered to minimize transition times for the internal cmos circuitry. the external level shifting circuitry is usually sufficient to accomplish this see the example applications section for a typical circuit. rx (pin5) the computer? rs232 transmit signal can be directly connected to this pin from the rs232 line as long as a current limiting resistor (typically about 47k w ) is installed in series. (internal protection diodes will pass the input currents safely to the supply connections, protecting the elm322.) internal signal inversion and schmitt trigger waveshaping provide the necessary signal conditioning. tx (pin 6) the rs232 data output pin. the signal level is compatible with most interface ics, and there is sufficient current drive to allow interfacing using only a single pnp transistor, if desired. obdout (pin 7) this is the active low output signal which is used to drive the obd bus to its active state. typically this is accomplished by switching a pnp type transistor on with the output from this pin. see the example application section for more details. v ss (pin 8) circuit common is connected to this pin. this is the most negative point in the circuit. elm322dsb
elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > elm322 electrical characteristics absolute maximum ratings storage temperature....................... -65? to +150? ambient temperature with power applied.................................... -40? to +85? voltage on v dd with respect to v ss ............ 0 to +7.5v voltage on any other pin with respect to v ss ........................... -0.6v to (v dd + 0.6v) note: stresses beyond those listed here will likely damage the device. these values are given as a design guideline only. the ability to operate to these levels is neither inferred nor recommended. 3 of 10 all values are for operation at 25? and a 5v supply, unless otherwise noted. for further information, refer to note 1 below. characteristic minimum typical maximum conditions units supply voltage, v dd 4.5 5.0 5.5 v v dd rate of rise 0.05 v/ms average supply current, i dd 1.0 2.4 ma notes: 1. this integrated circuit is produced with a microchip technology inc.? pic12c5xx as the core embedded microcontroller. for further device specifications, and possibly clarification of those given, please refer to the appropriate microchip documentation (available at http://www.microchip.com/). 2. this spec must be met in order to ensure that a correct power on reset occurs. it is quite easily achieved using most common types of supplies, but may be violated if one uses a slowly varying supply voltage, as may be obtained through direct connection to solar cells, or some charge pump circuits. 3. device only. does not include any load currents. 4. this specification represents the current flowing through the protection diodes when applying large voltages to the rx input (pin 5) through a current limiting resistance. currents quoted are the maximum that should be allowed to flow continuously. 5. nominal data transfer rate when a 3.58 mhz crystal is used as the frequency reference. data is transferred to and from the elm322 with 8 data bits, no parity, and 1 stop bit (8 n 1). input low voltage v ss 0.15 v dd v input high voltage v dd v 0.85 v dd output low voltage 0.6 v output high voltage v v dd - 0.7 current (sink) = 8.7ma current (source) = 5.4ma see note 2 elm322dsb see note 3 rx pin input current ma see note 4 -0.5 rs232 baud rate baud see note 5 9600 +0.5
4 of 10 elm322 elm322dsb elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > at commands the elm322 accepts internal configuration commands in much the same manner that modems do. any message received, at any time, that begins with the character ??followed by the character ??will be considered an internal configuration or ?t command. these are executed upon receipt of the terminating carriage return character, and successful completion of the command is acknowledged by the printing of the characters ?k? communicating with the elm322 the elm322 relies on a standard rs232 type serial connection to communicate with the user. the data rate is fixed at 9600 baud, with 8 data bits, no parity bit, 1 stop bit, and no handshaking (often referred to as 9600 8n1). all responses from the ic are terminated with only a single carriage return character, and no line feed character. some users may wish to improve readability by configuring their software to insert linefeed characters at the end of each line. properly connected and powered, the elm322 will initially display the message: elm322 v1.1 > in addition to identifying the version of the ic, receipt of this string is a convenient way to be sure that the computer connections and the settings are correct. however, at this point no communications have taken place with the vehicle, so the state of that connection is still unknown. the ??character displayed above is the elm322? prompt character. it indicates that the device is in its idle state, ready to receive characters on the rs232 port. characters sent from the computer can either be intended for the elm322? internal use, or for reformatting and passing on to the vehicle? obd bus. commands for the elm322 are distinguished from those to the vehicle by always beginning with the characters ?t?(as is common with modems), while commands for the obd bus must contain only the ascii characters for hexadecimal digits (0 to 9 and a to f). this allows the elm322 to quickly determine where the received characters are to be directed. whether an ?t?type internal command or a hex string for the obd bus, all messages to the elm322 must be terminated with a carriage return character (hex ?d? before it will be acted upon. the one exception is when an incomplete string is sent and no carriage return appears. in this case, an internal timer will automatically abort the incomplete message after about 10 seconds, and the elm322 will print a single question mark to show that the input was not understood (and was not acted upon). messages that are misunderstood by the elm322 (syntax errors) will always be signalled by a single question mark (??. these include incomplete messages, invalid at commands, or invalid hexadecimal digit strings. it is not an indication of whether or not the message was understood by the vehicle. (the elm322 is a protocol interpreter that makes no attempt to assess obd messages for validity - it only ensures that an even number of hex digits were received, combined into bytes, and sent out the obd port, so it cannot determine if the message sent to the vehicle is in error.) incomplete or misunderstood messages can also occur if the controlling computer attempts to write to the elm322 before it is ready to accept the next command (as there are no handshaking signals to control the data flow). to avoid a data overrun, users should always wait for the prompt character (?? before issuing the next command. finally, a few convenience items to note. the elm322 is not case-sensitive, so ?tz?is equivalent to ?tz? and to ?tz? the device ignores space characters as well as control characters (tab, linefeed, etc.) in the input, so they can be inserted anywhere to improve readability and, finally, issuing only a single carriage return character will repeat the last command (making it easier to request updates on dynamic data such as engine rpm). communications on the obd bus can generally begin without requiring the issuance of any at commands, as the factory default settings should be appropriate for most applications. occasionally the user may wish to customize settings, such as turning the character echo off, etc. in these cases, at commands must be issued. the following summarizes the at commands that are recognized by the current version of the elm322.
5 of 10 elm322 elm322dsb elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > obd commands if the bytes received on the rs232 bus do not begin with the letters a and t, they are assumed to be commands for the vehicle? obd bus. the bytes will be tested to ensure that they are valid pairs of hexadecimal digits and, if they are, will be combined into bytes for transmitting. recall that no checks are made as to the validity of the obd command ?data is simply retransmitted as received. obd commands are actually sent to the vehicle embedded in a data message. the standards require that every message begin with three header bytes and end with a checksum byte, which the elm322 adds automatically for the user (the header bytes never change in value, so are stored internally). to view the extra bytes that are received with the vehicle? messages, issue an ath1 internal command. most obd commands to the vehicle are one or two bytes in length, but some can be three or more bytes long. as the elm322 is considered an experimenter? circuit, it will only accept a maximum of three command bytes (or six hexadecimal digits) per message. attempts to send more will result in a syntax error, with the entire command being ignored and a single question mark being printed. the use of hexadecimal digits for all of the data exchange was chosen as it is the most common data format used in the relevant sae standards. it is consistent with mode request listings and is the most frequently used format for displaying results. with a little practice, it should not be very difficult to deal in hex numbers, but some people may want to obtain a conversion table or keep a calculator nearby. all users will be required to manipulate the results in some way though (combine bytes and divide by 4 to obtain rpm, divide by 2 to obtain degrees of advance, etc.) and may find a software front-end helpful. as an example of sending a command to the vehicle, assume that a6 (or decimal 166) is the command that is required to be sent. in this case, the user would type the letter a, then the number 6, then would press the return key. these three characters would be sent to the elm322 on the rs232 bus. the elm322 would store the characters as they are received, and when the third character (the carriage return) is received, begin to assess the other two. it would see that they are both valid hex digits, and would convert them to a one byte value (decimal value is 166). four header bytes would be added, and a total of five bytes would be sent to the vehicle. note that the carriage return character is only a signal to the elm322, and is not sent to the vehicle. after sending a command, the elm322 listens on the obd bus for any responses that are directed to it. each received byte is converted to the equivalent hexadecimal pair of ascii characters and transmitted on the rs232 port for the user. rather than send control characters which are unprintable on most terminals, the digits are sent as numbers and letters (eg. the hex digit ??is transmitted as decimal value 65, and not 10). if there was no response from the vehicle, due to no data being available, or because the command is not supported, a ?o data?message will be sent. see the error messages section for a description of this message and others. note that they are not case-sensitive, and that the character ??is the number ?ero? ate0 and ate1 these commands control whether characters received on the rs232 port are retransmitted (or echoed) back to the host computer. to reduce traffic on the rs232 bus, users may wish to turn echoing off by issuing ate0. echo is initially on at powerup (default) and can be turned on at any time by issuing ate1. ath0 and ath1 these commands control whether or not the header information is shown in the responses. all obd messages have an initial (header) string of three bytes and a trailing check digit (crc character) that is normally not displayed by the elm322. to see this extra information, users should turn headers on by issuing ath1. the default is h0 (headers off). atz this combination causes the chip to perform a complete reset as if power were cycled off and then on again. all settings are returned to their default values, and the chip will be put in the idle state, waiting for characters on the rs232 bus.
6 of 10 elm322 elm322dsb elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > talking to the vehicle the elm322 cannot be directly connected to a vehicle as it is, but needs support circuitry as shown in the example applications section. once incorporated into such a circuit, one need only use a terminal program to send bytes to, and receive them from the vehicle via the elm322. sae standards specify that command bytes sent to the vehicle must adhere to a set format. the first byte (known as the ?ode? always describes the type of data being requested, while the second, third, etc. bytes specify the actual information required (given by a ?arameter identification?or pid number). the modes and pids are described in detail in the sae documents j1979 and j2190, and may also be expanded on by the vehicle manufacturers. normally, one is only concerned with the nine diagnostic test modes described in j1979 (although there is provision for more). note that it is not a requirement for all of them to be supported. these are the nine modes: 01 : show current data 02 : show freeze frame data 03 : show diagnostic trouble codes 04 : clear trouble codes and stored values 05 : test results, oxygen sensors 06 : test results, non-continuously monitored 07 : test results, continuously monitored 08 : special control mode 09 : request vehicle information within each mode, pid 00 is normally reserved to show which pids are supported by that mode. mode 01, pid 00 must be supported by all vehicles, and can be accessed as follows ensure that the elm322 is properly connected to your vehicle, and powered. most vehicles will not respond without the ignition key in the on position, so turn the ignition on, but do not start the vehicle. at the prompt, issue the mode 01 pid 00 command: >01 00 a typical response could be as follows: 41 00 be 1f b8 10 the 41 00 signifies a response (4) from a mode 1 request from pid 00 (a mode 2, pid 00 request is answered with a 42 00, etc.). the next four bytes (be, 1f, b8, and 10) represent the requested data, in this case a bit pattern showing which of pids 1 through 32 are supported by this mode (1=supported, 0=not). although this information is not very useful for the casual user, it does serve to show that you are communicating with the vehicle. another example requests the current engine coolant temperature (ect). this is pid 05 in mode 01, and is requested as follows: >01 05 the response will be of the form: 41 05 7b this shows a mode 1 response (41) from pid 05, with value 7b. converting the hexidecimal 7b to decimal, one gets 7 x 16 + 11 = 123. this represents the current temperature in degrees celsius, with the zero value offset to allow operation at subzero temperatures. to convert to the actual coolant temperature, simply subtract 40 from the value. in this case then, the ect is 123 - 40 = 83 deg c. a final example shows a request for the obd requirements to which this vehicle was designed. this is pid 1c of mode 01, so at the prompt, type: >01 1c a typical response would be: 41 1c 01 the returned value (01) shows that this vehicle conforms to obdii (california arb) standards. the presently defined responses are : 01 : obdii (california arb) 02 : obd (federal epa) 03 : obd and obdii 04 : obd i 05 : not intended to meet any obd requirements 06 : eobd (europe) some modes may provide multi-line responses (09, if supported, can display the vehicle? serial number). the elm322 will attempt to display all responses in these cases, but only if it is allowed sufficient time to process each. there may be occasions when the vehicle responds too quickly to allow time for reprocessing, and lines could be lost. hopefully this has shown how typical requests proceed. it has not been meant to be a definitive source on modes and pids ?this information can be obtained from the sae (http://www.sae.org/), from the manufacturer of your vehicle, iso (http://iso.org/), or from various other sources on the web.
interpreting trouble codes 7 of 10 elm322 elm322dsb elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > likely the most common use that the elm322 will be put to is in obtaining the current diagnostic trouble codes or dtcs. minimally, this requires that a mode 03 request be made, but first one should determine how many trouble codes are presently stored. this is done with a mode 01 pid 01 request as follows: >01 01 to which a typical response might be: 41 01 81 07 65 04 the 41 01 signifies a response to our request, and the first data byte (81) is the result that we are looking for. clearly there would not be 81(hex) or 129(decimal) trouble codes if the vehicle is operational. in fact, this byte does double duty, with the most significant bit being used to indicate that the malfunction indicator lamp (mil, or ?heck engine? has been turned on by one of this module? codes (if there are more than one), while the other 7 bits provide the actual number of stored codes. to determine the number of stored codes then, one needs to subtract 128 (or 80 hex) from the number if it is greater than 128, and otherwise simply read the number of stored codes directly. the above response then indicates that there is one stored code, and it was the one that set the check engine lamp or mil on. the remaining bytes in the response provide information on the types of tests supported by that particular module (see sae document j1979 for further information). in this instance, there was only one line to the response, but if there were codes stored in other modules, they each could have provided a line of response. to determine which module is reporting the trouble code, one would have to turn the headers on (ath1) and then look at the third byte of the three byte header for the address of the module that sent the information. having determined the number of codes stored, the next step is to request the actual trouble codes with a mode 03 request: >03 a response to this could be: 43 01 33 00 00 00 00 the ?3?in the above response simply indicates that this is a response to a mode 03 request. the other 6 bytes in the response have to be read in pairs to show the trouble codes (the above would be interpreted as 0133, 0000, and 0000). note that there is only one trouble code here. the response has been padded with 00? as is required by the standard, and the extra 0000? do not represent actual trouble codes. as was the case when requesting the number of stored codes, the most significant bits of each trouble code also contain additional information. it is easiest to use the following table to interpret the first digit of trouble codes as follows: powertrain codes - sae defined 0 ? ? - manufacturer defined ? ? - sae defined ? ? - jointly defined 1 2 3 if the first hex digit received is this, replace it with these two characters chassis codes - sae defined 4 ? ? - reserved for future 5 6 7 body codes - sae defined 8 9 a b network codes - sae defined c d e f p0 p1 p2 p3 c0 c1 c2 c3 b0 b1 b2 b3 u0 u1 u2 u3 ? ? - reserved for future ? ? - manufacturer defined ? ? - manufacturer defined ? ? - manufacturer defined ? ? - manufacturer defined ? ? - manufacturer defined ? ? - manufacturer defined ? ? - reserved for future taking the example trouble code (0133), the first digit (0) would then be replaced with p0, and the 0133 reported would become p0133 (which is the code for an ?xygen sensor circuit slow response?. as for further examples, if the response had been d016, the code would be interpreted as u1016, while a 1131 would be p1131. had there been codes stored by more than one module, or more than three codes stored in the same module, the above response would have consisted of multiple lines. to determine which module is reporting each trouble would then require turning the headers on with an ath1 command.
error messages 8 of 10 elm322 elm322dsb elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > resetting trouble codes when hardware or data problems are encountered, the elm322 will respond with one of the following short messages. here is a brief description of each: bus busy the elm322 tried to send the mode command or request for about 0.5 seconds without success. messages are all assigned priorities, which allows one message to take precedence over another. more important things may have been going on, so try re-issuing your request. bus error an attempt was made to send a message, and the data bus voltage did not respond as expected. this could be because of a circuit short or open, so check all of your connections and try once more. data error there was a response from the vehicle, but the information could not be recovered. most likely it did not contain enough bytes to be a valid message, which can occur if a ?reak?signal is issued by another module. example application 9 of 10 the sae j1962 standard dictates that all obd compliant vehicles must provide a standard connector near the driver? seat, the shape and pinout of which is shown in figure 1 below. the circuitry described here will be used to connect to this plug without modification to your vehicle. the male j1962 connector required to mate with a vehicle? connector may be difficult to obtain in some locations, and you could be tempted to improvise by making your own connections to the back of your vehicle? connector. if doing so, we recommend that you do nothing which would compromise the integrity of your vehicle? obd network. the use of any connector which could easily short pins (such as an rj11 type telephone connector) would definitely not be recommended. the circuit of figure 2 on the next page shows how the elm322 would typically be used. circuit power is obtained from the vehicle (obd pins 16 and 5) and, after some minor filtering, is presented to a five volt regulator. notice that the common point of the regulator is returned to vehicle ground through a diode and a (red or green) led, effectively raising circuit common about 2.5 to 3 volts above vehicle common. this gives a net 7.5 to 8 volt positive supply for the obd bus, as required by the standard (the ground signal shown throughout the schematic refers to the circuit common and not chassis ground). note that by offsetting the regulator in this way, the led and the 750 w resistor (which provides the current for the led) become critical components that must not be eliminated. also, one other subtle result of this is that one must take care not to connect the vehicle? common to the computer? common, as the led will be shorted out, reducing the supply to 5 volts which is below the required level. the remaining connection to the obd bus (pin 2) is the data line required for communications. data is transmitted onto the bus from the elm322 via the pnp transistor, the diode, and the 100 w current limiting resistor (which also provides moderate waveshaping). the diode is needed to protect the circuitry from backfeeds from overvoltages that could be present on the bus. note that the 10k w pulldown or loading resistor returns to vehicle common, providing the data bus with a full (7.5v) voltage swing. data is received from the obd bus and level shifted by the npn transistor shown connected to pin 4 of the elm322. using a transistor this way forces the logic transition point to be at about 3v (the voltage elm322 elm322dsb elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > drops of two diodes and an led) with respect to vehicle common. had the input been directly connected to pin 4, the threshold would have been approximately 5 volts - much higher than the 3.5 volts specified by the standard. a very basic rs232 interface is shown connected to pins 5 and 6 of the elm322. this circuit ?teals power from the host computer in order to provide a full swing of the rs232 voltages, without the need for a negative supply. the rs232 pin connections shown are for a 25 pin connector. if you are using a 9 pin, the connections would be 2(rxd), 5(sg) and 3(txd). rs232 data from the computer is directly connected to pin 5 of the ic through only a 47k w current limiting resistor. this resistor allows for voltage swings in excess of the supply levels while preventing damage to the elm322. a single 100k w resistor is also shown in this circuit so that pin 5 is not left floating if the computer is disconnected. transmission of rs232 data is via the single pnp transistor connected to pin 6. this transistor allows the output voltage to swing between +5v and the negative voltage stored on the 0.1? capacitor (which is charged by the computer? txd line). although it is a simple connection, it is quite effective for this type of application. finally, the crystal shown connected between pins 2 and 3 is a common tv type that can be easily and inexpensively obtained. the 27pf crystal loading capacitors shown are typical only, and you may have to select other values depending on what is specified for the crystal you obtain. this completes the description of the circuit. while it is the minimum required to talk to an obd equipped vehicle, it is still a fully functional circuit. as an experimenter, you may want to expand on it, providing more protection from faults and electrostatic discharge, or providing a different interface for the rs232 connection to the computer. then perhaps a basic program to make it easier to talk to the vehicle, and a method to log your findings, and figure 1. vehicle connector 1 9 8 1 6
?ower on led 10 of 10 elm322 elm322dsb elm electronics ?circuits for the hobbyist < http://www.elmelectronics.com/ > figure 2. typical obd to rs232 interface 3 (rxd) 7 (sg) 2 (txd)
|
